home *** CD-ROM | disk | FTP | other *** search
-
- Network Working Group Steve Kille, WG Chair
- Internet Draft Ned Freed, Editor
-
-
-
-
-
- Network Services Monitoring MIB
-
- 7-Sep-1993
-
-
-
-
-
- Status of this Memo
-
- This document is an Internet Draft. Internet Drafts are working
- documents of the Internet Engineering Task Force (IETF), its Areas, and
- its Working Groups. Note that other groups may also distribute working
- documents as Internet Drafts.
-
- Internet Drafts are valid for a maximum of six months and may be
- updated, replaced, or obsoleted by other documents at any time. It is
- inappropriate to use Internet Drafts as reference material or to cite
- them other than as a "work in progress".
-
-
- Table of Contents
-
- 1 Introduction .................................................... 2
- 2 The SNMPv2 Network Management Framework ......................... 2
- 2.1 Object Definitions ............................................ 2
- 3 Rationale for having a Network Services Monitoring MIB .......... 3
- 3.1 Restriction of Scope .......................................... 3
- 3.2 Relationship to Directory Services ............................ 4
- 4 Application Objects ............................................. 5
- 5 Definitions ..................................................... 6
- 6 Acknowledgements ................................................ 16
- 7 Security Considerations ......................................... 16
- 8 Authors' Addresses .............................................. 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- 1. Introduction
-
- This document defines the generic part of a MIB suitable for monitoring
- applications which provide some variety of network service. This MIB is
- intended to be extended to accomodate monitoring specific to a given
- type of service, for example, a Message Transfer Agent (MTA) service or
- a Directory Service Agent (DSA) service.
-
-
- 2. The SNMPv2 Network Management Framework
-
- The SNMPv2 Network Management Framework consists of four major
- components. They are:
-
- o RFC 1442 which defines the SMI, the mechanisms used for describing
- and naming objects for the purpose of management.
-
- o RFC 1213 defines MIB-II, the core set of managed objects for the
- Internet suite of protocols.
-
- o RFC 1445 which defines the administrative and other architectural
- aspects of the framework.
-
- o RFC 1448 which defines the protocol used for network access to
- managed objects.
-
- The Framework permits new objects to be defined for the purpose of
- experimentation and evaluation.
-
-
- 2.1. Object Definitions
-
- Managed objects are accessed via a virtual information store, termed the
- Management Information Base or MIB. Objects in the MIB are defined
- using the subset of Abstract Syntax Notation One (ASN.1) defined in the
- SMI. In particular, each object type is named by an OBJECT IDENTIFIER,
- an administratively assigned name. The object type together with an
- object instance serves to uniquely identify a specific instantiation of
- the object. For human convenience, we often use a textual string,
- termed the descriptor, to refer to the object type.
-
-
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 2]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- 3. Rationale for having a Network Services Monitoring MIB
-
- Much effort has been expended in developing tools to manage lower layer
- network facilities. However, relatively little work has been done on
- managing application layer entities. It is neither efficient nor
- reasonable to manage all aspects of application layer entities using
- only lower layer information. Moreover, the difficulty of managing
- application entities in this way increases dramatically as application
- entities become more complex.
-
- This leads to a substantial need to monitor applications which provide
- network services, particularly distributed components such as MTAs and
- DSAs, by monitoring specific aspects of the application itself. Reasons
- to monitor such components include but are not limited to measuring
- load, detecting broken connectivity, isolating system failures, and
- locating congestion.
-
- In order to manage network service applications effectively two
- requirements must be met:
-
- (1) It must be possible to monitor a large number of components
- (typical for a large organization).
-
- (2) Application monitoring must be integrated into general network
- management.
-
- SNMP is the clear choice for this sort of monitoring. At present only
- simple read-only access is defined; this is sufficient to determine
- up/down status and provide an indication of a broad class of operational
- problems.
-
-
- 3.1. Restriction of Scope
-
- The framework provided here is very minimal; there is a lot more that
- could be done. For example:
-
- (1) General network service application configuration monitoring and
- control.
-
- (2) Detailed examination and modification of individual entries in
- service-specific request queues.
-
- (3) Probing to determine the status of a specific request (e.g. the
- location of a mail message with a specific message-id).
-
-
-
-
-
- Expires 7-Mar-1994 [Page 3]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- (4) Requesting that certain actions be performed (e.g. forcing an
- immediate connection and transfer of pending messages to some
- specific system).
-
- All these capabilities are both impressive and useful. However, these
- capabilities would require provisions for strict security checking.
- These capabilities would also mandate a much more complex design, with
- many characteristics likely to be fairly implementation-specific. As a
- result such facilities are likely to be both contentious and difficult
- to implement.
-
- This document religiously keeps things simple and focuses on the basic
- monitoring aspect of managing applications providing network services.
- The goal here is to provide a framework which is simple, useful, and
- widely implementable.
-
-
- 3.2. Relationship to Directory Services
-
- Use of and management of directory services already is tied up with
- network service application management. There are clearly many things
- which could be dealt with by directory services and protocols. We take
- the line here that static configuration information is both provided by
- and dealt with by directory services and protocols. The emphasis here
- is on transient application status.
-
- By placing static information in the directory, the richness and linkage
- of the directory information framework does not need to be repeated in
- the MIB. Static information is information which has a mean time to
- change of the order of days or longer.
-
- When network service applications that employ directory services are
- monitored, it is recommend that a linkage be established, so that:
-
- (1) The managed object contains its own directory name. This allows
- all directory information to be obtained by reference. This will
- let a SNMP monitor capable of performing directory queries present
- this information to the manager in an appropriate format. It is
- intended that this will be the normal case.
-
- (2) The directory will reference the location of the SNMP agent, so
- that an SNMP capable directory query agent could probe dynamic
- characteristics of the object.
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 4]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- (3) This approach could be extended further, so that the SNMP
- attributes are modelled as directory attributes. This would
- dramatically simplify the design of directory service agents that
- use SNMP to obtain the information they need.
-
-
- 4. Application Objects
-
- This MIB starts with a set of general purpose attributes which would be
- appropriate for a range of applications that provide network services.
- Both OSI and non-OSI services can be accomodated. Additional tables
- defined in extensions to this MIB provide attributes specific to
- specific network services.
-
- A table is defined which will have one row for each network service
- application running on the system. The only static information held on
- the application is its name. All other static information should be
- obtained from various directory services. The applName is an external
- key, which allows an SNMP MIB entry to be cleanly related to the X.500
- Directory. In SNMP terms, the applications are grouped in a table
- called applTable, which is indexed by an integer key applIndex.
-
- The type of the application will be determined by one or both of:
-
- (1) Additional MIB variables specific to the applications.
-
- (2) An association to the application of a specific protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 5]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- 5. Definitions
-
- APPLICATION-MIB DEFINITIONS ::= BEGIN
-
- IMPORTS
- OBJECT-TYPE, experimental, Counter32, Gauge32
- FROM SNMPv2-SMI
- DisplayString, TimeStamp
- FROM SNMPv2-TC;
-
- application MODULE-IDENTITY
- LAST-UPDATED "9309070000Z"
- ORGANIZATION "IETF Mail and Directory Management Working Group"
- CONTACT-INFO
- " Ned Freed
-
- Postal: Innosoft International, Inc.
- 250 West First Street, Suite 240
- Claremont, CA 91711
- US
-
- Tel: +1 909 624 7907
- Fax: +1 909 621 5319
-
- E-Mail: ned@innosoft.com"
- DESCRIPTION
- "The MIB module describing network service applications"
- ::= {experimental 46}
-
- applObjects OBJECT IDENTIFIER ::= {application 1}
-
-
- -- The basic applTable contains a list of the application
- -- entities.
-
- applTable OBJECT-TYPE
- SYNTAX SEQUENCE OF ApplEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The table holding objects which apply to all different
- kinds of applications providing network services."
- ::= {applObjects 1}
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 6]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- applEntry OBJECT-TYPE
- SYNTAX ApplEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry associated with a network service application."
- INDEX {applIndex}
- ::= {applTable 1}
-
- ApplEntry ::= SEQUENCE {
- applIndex
- INTEGER,
- applName
- DisplayString,
- applVersion
- DisplayString,
- applUptime
- TimeStamp,
- applOperStatus
- INTEGER,
- applLastChange
- TimeStamp,
- applInboundAssociations
- Gauge32,
- applOutboundAssociations
- Gauge32,
- applAccumulatedInboundAssociations
- Counter32,
- applAccumulatedOutboundAssociations
- Counter32,
- applLastInboundActivity
- TimeStamp,
- applLastOutboundActivity
- TimeStamp,
- applRejectedInboundAssociations
- Counter32,
- applFailedOutboundAssociations
- Counter32
- }
-
-
-
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 7]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- applIndex OBJECT-TYPE
- SYNTAX INTEGER (1..2147483647)
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An index to uniquely identify the network service
- application."
- ::= {applEntry 1}
-
- applName OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The name the network service application chooses to be
- known by."
- ::= {applEntry 2}
-
- applVersion OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The version of network service application software."
- ::= {applEntry 3}
-
- applUptime OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time the network service
- application was last initialized. If the application was
- last initialized prior to the last initialization of the
- network management subsystem, then this object contains
- a zero value."
- ::= {applEntry 4}
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 8]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- applOperStatus OBJECT-TYPE
- SYNTAX INTEGER {
- up(1),
- down(2),
- halted(3),
- congested(4),
- restarting(5)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Indicates the operational status of the network service
- application. 'down' indicates that the network service is
- not available. 'running' indicates that the network service
- is operational and available. 'halted' indicates that the
- service is operational but not available. 'congested'
- indicates that the service is operational but no additional
- inbound associations can be accomodated. 'restarting'
- indicates that the service is currently unavailable but is
- in the process of restarting and will be available soon."
- ::= {applEntry 5}
-
- applLastChange OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time the network service
- application entered its current operational state. If
- the current state was entered prior to the last
- initialization of the local network management subsystem,
- then this object contains a zero value."
- ::= {applEntry 6}
-
- applInboundAssociations OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of current associations to the network service
- application, where it is the responder. For dynamic single
- threaded processes, this will be the number of application
- instances."
- ::= {applEntry 7}
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 9]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- applOutboundAssociations OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of current associations to the network service
- application, where it is the initiator. For dynamic single
- threaded processes, this will be the number of application
- instances."
- ::= {applEntry 8}
-
- applAccumulatedInboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of associations to the application entity
- since application initialization, where it was the responder.
- For dynamic single threaded processes, this will be the
- number of application instances."
- ::= {applEntry 9}
-
- applAccumulatedOutboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of associations to the application entity
- since application initialization, where it was the initiator.
- For dynamic single threaded processes, this will be the
- number of application instances."
- ::= {applEntry 10}
-
- applLastInboundActivity OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time this application last
- had an inbound association. If the last association
- occurred prior to the last initialization of the network
- subsystem, then this object contains a zero value."
- ::= {applEntry 11}
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 10]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- applLastOutboundActivity OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time this application last
- had an outbound association. If the last association
- occurred prior to the last initialization of the network
- subsystem, then this object contains a zero value."
- ::= {applEntry 12}
-
- applRejectedInboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of inbound associations the application
- entity has rejected, since application initialization."
- ::= {applEntry 13}
-
- applFailedOutboundAssociations OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number associations where the application entity
- is initiator and association establishment has failed,
- since application initialization."
- ::= {applEntry 14}
-
-
- -- assocTable augments the information in applTable with data
- -- about associations. This is treated as a separate group to
- -- the basic application table. Where simplified appplication
- -- monitoring is needed, the assocTable group may be omitted.
- -- This table is indexed by applIndex and assocIndex, with the
- -- application index coming first.
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 11]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- assocTable OBJECT-TYPE
- SYNTAX SEQUENCE OF AssocEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "The table holding a set of all active application
- associations."
- ::= {applObjects 2}
-
- assocEntry OBJECT-TYPE
- SYNTAX AssocEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry associated with an association for a network
- service application."
- INDEX {applIndex, assocIndex}
- ::= {assocTable 1}
-
- AssocEntry ::= SEQUENCE {
- assocIndex
- INTEGER,
- assocRemoteApplication
- DisplayString,
- assocApplicationProtocol
- OBJECT IDENTIFIER,
- assocApplicationType
- INTEGER,
- assocDuration
- TimeStamp
- }
-
- assocIndex OBJECT-TYPE
- SYNTAX INTEGER (1..2147483647)
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An index to uniquely identify each association for a network
- service application."
- ::= {assocEntry 1}
-
-
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 12]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- assocRemoteApplication OBJECT-TYPE
- SYNTAX DisplayString
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The name of the system running remote network service
- application. For an IP-based application this should be
- either a domain name or IP address. For an OSI application
- it should be the string encoded distinguished name of the
- managed object. For X.400(84) MTAs which do not have a
- Distinguished Name, the RFC-1327 syntax 'mta in globalid'
- should be used."
- ::= {assocEntry 2}
-
- assocApplicationProtocol OBJECT-TYPE
- SYNTAX OBJECT IDENTIFIER
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "An identification of the protocol being used for the
- application. For an OSI Application, this will be the
- Application Context. For Internet applications, the IANA
- maintains a registry of the OIDs which correspond
- to well-known applications. If the application protocol is
- not listed in the registry, the value {applProtoID port} is
- used where 'port' corresponds to primary port being used by
- the application."
- ::= {assocEntry 3}
-
- assocApplicationType OBJECT-TYPE
- SYNTAX INTEGER {
- ua-initiator(1),
- ua-responder(2),
- peer-initiator(3),
- peer-responder(4) }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "Shows whether the remote application is a User Agent, or a
- peer server, and whether the remote end is initiator or
- responder."
- ::= {assocEntry 4}
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 13]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- assocDuration OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime at the time this association was
- started. If this association started prior to the last
- initialization of the network subsystem, then this
- object contains a zero value."
- ::= {assocEntry 5}
-
-
- -- Conformance information
-
- applConformance OBJECT IDENTIFIER ::= {application 2}
-
- applGroups OBJECT IDENTIFIER ::= {applConformance 1}
- applCompliances OBJECT IDENTIFIER ::= {applConformance 2}
-
-
- -- Compliance statements
-
- applCompliance MODULE-COMPLIANCE
- STATUS current
- DESCRIPTION
- "The compliance statement for SNMPv2 entities
- which implement the Network Services Monitoring MIB
- for basic monitoring of network service applications."
- MODULE -- this module
- MANDATORY-GROUPS {applGroup}
- ::= {applCompliances 1}
-
- assocCompliance MODULE-COMPLIANCE
- STATUS current
- DESCRIPTION
- "The compliance statement for SNMPv2 entities
- which implement the Network Services Monitoring MIB
- for basic monitoring of network service applications
- and their associations."
- MODULE -- this module
- MANDATORY-GROUPS {applGroup, assocGroup}
- ::= {applCompliances 2}
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 14]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- -- Units of conformance
-
- applGroup OBJECT-GROUP
- OBJECTS {
- applIndex, applName, applVersion, applUptime,
- applOperStatus, applLastChange, applInboundAssociations,
- applOutboundAssociations, applAccumulatedInboundAssociations,
- applAccumulatedOutboundAssociations, applLastInboundActivity,
- applLastOutboundActivity, applRejectedInboundAssociations,
- applFailedOutboundAssociations }
- STATUS current
- DESCRIPTION
- "A collection of objects providing basic monitoring of
- network service applications."
- ::= {applGroups 1}
-
- assocGroup OBJECT-GROUP
- OBJECTS {
- assocIndex, assocRemoteApplication,
- assocApplicationProtocol, assocApplicationType,
- assocDuration }
- STATUS current
- DESCRIPTION
- "A collection of objects providing basic monitoring of
- network service applications' associations."
- ::= {applGroups 2}
-
-
- -- Values of the form { applProtoID port } are used for
- -- protocols that don't have assigned OIDs. 'port'
- -- corresponds to primary port being used by the
- -- application.
-
- applProtoID OBJECT IDENTIFIER ::= {application 3}
-
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 15]
-
-
-
-
-
- Internet Draft Network Services Monitoring MIB 7-Sep-1993
-
-
- 6. Acknowledgements
-
- This document is a product of the Mail and Directory Management (MADMAN)
- Working Group. It is based on an earlier MIB designed by S. Kille, T.
- Lenggenhager, D. Partain, and W. Yeong.
-
-
- 7. Security Considerations
-
- Security issues are not discussed in this memo.
-
-
- 8. Authors' Addresses
-
- Ned Freed, Editor
- Innosoft International, Inc.
- 250 West First Street, Suite 240
- Claremont, CA 91711
- USA
- tel: +1 909 624 7907
- fax: +1 909 621 5319
- email: ned@innosoft.com
-
- Steve Kille, WG Chair
- ISODE Consortium
- P.O. Box 505
- London SW11 1DX
- UK
- tel: +44 71 223 4062
- email: S.Kille@isode.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires 7-Mar-1994 [Page 16]
-
-
-